home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000382_news@columbia.edu_Wed Dec 7 14:04:55 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12173
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 9 Dec 1994 23:58:43 -0500
  3. Received: by apakabar.cc.columbia.edu id AA19901
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 9 Dec 1994 23:58:42 -0500
  5. Newsgroups: comp.protocols.kermit.misc
  6. Path: news.columbia.edu!spcuna!solaris.cc.vt.edu!news.mathworks.com!usenet.eel.ufl.edu!usenet.cis.ufl.edu!caen!hearst.acc.Virginia.EDU!murdoch!fulton.seas.Virginia.EDU!esh6h
  7. From: esh6h@fulton.seas.Virginia.EDU (Erik Hatcher)
  8. Subject: Re: Server side renames - still not solved!
  9. Message-Id: <D0G1s8.CBo@murdoch.acc.Virginia.EDU>
  10. Sender: usenet@murdoch.acc.Virginia.EDU
  11. Organization: University of Virginia
  12. References: <D0CyFn.4sv@murdoch.acc.virginia.edu> <3c2240$5uh@apakabar.cc.columbia.edu>
  13. Date: Wed, 7 Dec 1994 14:04:55 GMT
  14. Lines: 48
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3c2240$5uh@apakabar.cc.columbia.edu>,
  18. Jeffrey Altman <jaltman@watsun.cc.columbia.edu> wrote:
  19. >Erik:
  20. >
  21. >The answer appears to be that at this time server side RENAME
  22. >is not possible unless you lower the security barriers a bit
  23. >which you do not want to do.
  24.  
  25. No I'm not willing to compromise our system security to
  26. rename a file!  :)
  27.  
  28. >The only suggestion that I have for you is to perform the rename
  29. >on the client before you send the file.  Or just send the file
  30. >with the name is it supposed to the saved under from the very 
  31. >start.
  32. >
  33. >SEND oldname newname
  34. >
  35. >has exactly the same result as 
  36. >
  37. >SEND oldname
  38. >REMOTE RENAME oldname newname
  39.  
  40. But it is not "exactly" the same result, is it?
  41.  
  42. One creates a file called "newname" from the start.
  43. The other only creates "newname" after the entire
  44. file is successfully sent (assuming that REMOTE RENAME
  45. isn't done "if failure").
  46.  
  47. The reason I want/need REMOTE RENAME is so that my
  48. automatic process to pick up received files on the
  49. remote end, doesn't try to pick up a file being sent
  50. or not successfully sent.  It only picks up files
  51. with the name REC_*.* and they are sent as SENDING_*.*.
  52.  
  53. Frank mentioned that he'll put it in the next version,
  54. so I'm fine with that!  Thanks a million Frank!
  55.  
  56. BTW, not being pushy, but how often do new versions
  57. get released?
  58.  
  59.     Erik
  60. --
  61. Erik Hatcher                           + "But every now and then we just have
  62. http://fulton.seas.virginia.edu/~esh6h |  to howl with the wolves." 
  63.                                        |        - Werner Heisenberg
  64. ---------------------------------------+-------------------------------------